Read the original article here.

---

Alright, cadet. Forget what they told you in your intro classes. This isn't about printing "Hello, World!" in five different languages. This is about looking underneath the hood. This is about the raw commands that make the silicon dance. They don't push this stuff because it's complex, sure, but also because once you understand it, you see the machine not as a black box, but as a collection of tiny, obedient circuits waiting for orders.

This is your primer on Opcodes – the core vocabulary of the digital world, often hidden, rarely explained in plain sight. It's a key piece of the "Forbidden Code."

---

The Forbidden Code: Understanding Opcodes

In the world of computers, everything ultimately boils down to manipulating bits and bytes based on instructions. At the very lowest level, these instructions are numerical codes, commands understood directly by the processing unit. These codes are called opcodes.

Definition: Opcode (Operation Code)

An enumerated value (a specific number or binary pattern) that precisely defines the action or operation a processor (either hardware or software-based) should perform. It's the core command within a machine instruction.

Think of it like a single verb in the computer's native language. Every fundamental action – adding numbers, moving data, checking a condition – has a specific opcode assigned to it. Without opcodes, the processor is just a complex piece of inert metal and plastic. Opcodes bring it to life, telling it what to do.

While the concept is simple, the implementation varies. Opcodes are fundamental to:

1. Hardware Devices: Like the Arithmetic Logic Unit (ALU) or the Central Processing Unit (CPU). Here, the opcode directly controls the circuitry.
2. Software Instruction Sets: Used in virtual machines and interpreters, where a software layer executes code based on opcodes from an intermediate format (like bytecode).

Understanding opcodes is crucial if you ever want to truly understand assembly language, reverse engineer software, analyze malware, write performance-critical code, or even dabble in security exploits.

---

Opcodes in the Wild: CPUs and Machine Language

When you compile a program written in C, Python, or any other language, it eventually gets translated into machine code. Machine code is the sequence of bytes that the CPU directly executes. Within this sequence, each distinct operation is represented by an opcode.

Additional Context: Machine Language

The lowest-level programming language, consisting of binary instructions directly understandable by a computer's CPU. It's hardware-dependent, meaning machine code for one type of CPU (like Intel x86) won't run directly on another (like ARM) without translation or emulation. Each instruction in machine language typically consists of an opcode and its associated operands (data or memory addresses to operate on).

In the realm of CPUs, opcodes go by several aliases depending on the specific processor architecture or the context:

• Instruction Machine Code
• Instruction Code
• Instruction Syllable (especially if instructions have fixed-size parts)
• Instruction Parcel
• Opstring

The complete set of opcodes that a particular processor understands is defined by its Instruction Set Architecture (ISA). The ISA is like the processor's official rulebook and dictionary.

Definition: Instruction Set Architecture (ISA)

The abstract model that defines how software interacts with a processor. It specifies the set of instructions the processor can execute (including their opcodes and formats), the available registers, memory addressing modes, interrupt handling, and other fundamental behaviors visible to a programmer or compiler writer. Examples include x86, ARM, MIPS, RISC-V.

The types of operations encoded by opcodes cover the fundamental building blocks of computation:

• Arithmetic Operations: Addition, subtraction, multiplication, division, etc. (e.g., ADD, SUB, MUL, DIV)
• Logical Operations: AND, OR, XOR, NOT, shifts, rotations. (e.g., AND, OR, XOR, SHL, ROR)
• Data Copying/Movement: Moving data between registers, between memory and registers, or loading constant values. (e.g., MOV, LOAD, STORE)
• Program Control (Control Flow): Jumping to a different part of the code, calling subroutines, returning from subroutines, conditional branching based on flags. (e.g., JMP, CALL, RET, JE (Jump if Equal), JNE (Jump if Not Equal))
• Special Instructions: Specific processor control, I/O operations, status checks, etc. (e.g., NOP (No Operation), CPUID (get CPU info on x86), SYSCALL)

An instruction often consists of more than just the opcode. It also needs to specify the operands – the data or memory locations the operation should act upon. For example, an ADD opcode needs to know what to add.

Definition: Operand

A piece of data or a location (like a register or memory address) that an instruction's operation will use or modify. Operands provide the "with what" or "on what" for the opcode's "do this".

While many instructions require explicit operands (e.g., ADD RegisterA, RegisterB), some have implicit operands (e.g., an instruction to increment a specific status register might not list an operand) or no operands at all (e.g., a NOP instruction does nothing).

The structure of machine instructions, and thus where the opcode and operand information are located, varies significantly between different ISAs. Some have very regular, fixed-length instructions where the opcode field is always in the same place (common in RISC architectures). Others, like the ubiquitous x86 architecture, use a variable-length instruction format where the opcode can be one or more bytes, potentially followed by prefixes and operand specifiers in a less uniform structure. This variability is one reason x86 machine code can be notoriously complex to parse manually.

---

Peering into the Machine: A Sample Opcode Structure (Intel 8008)

To truly appreciate the low-level nature of opcodes, let's look at a historical example, the Intel 8008 microprocessor from 1972. This chip, an ancestor of modern Intel CPUs, had a relatively simple 8-bit architecture, making its opcode structure illustrative.

Every instruction opcode on the 8008 was exactly 8 bits long. But here's the crucial part: sometimes, these 8 bits didn't just specify the operation. They could also embed information about the operands directly within the opcode itself!

Let's break down what this means based on how the 8008 worked:

• The 8 Bits: The opcode is a single byte (8 bits), like 01011010.
• Fixed vs. Variable Fields: Within that 8-bit pattern, some bits are fixed (always 0 or 1 for a specific type of instruction), while others are variable fields that specify parameters.
• Embedded Operands: The 8008 used 3-bit fields embedded within the opcode to specify registers or other parameters. Common fields included:
  • DDD: Destination register (3 bits, could specify one of 8 registers: A, B, C, D, E, H, L, or memory location M addressed by H/L).
  • SSS: Source register (3 bits, same options as DDD).
  • CC: Condition code (3 bits, specifies a condition like "zero flag is set" or "carry flag is clear" for conditional jumps/calls/returns).
  • ALU: Arithmetic/Logic Unit function (3 bits, specifies which ALU operation like add, subtract, AND, OR, etc.).
• 'X' for Don't Care: Some bits in the opcode pattern might be marked with 'X', meaning their value (0 or 1) doesn't affect the instruction's meaning.
• Putting it Together: A specific operation like "Move the contents of register SSS to register DDD" might be encoded with a pattern like 11DDDSSS. The 11 indicates the "Move" operation type, and the following 6 bits directly specify the source and destination registers within the opcode byte.
• Additional Operands: Some instructions required more data than could be embedded in the 8-bit opcode (e.g., loading a 16-bit address or an 8-bit immediate value). In such cases, the instruction would consist of the opcode byte followed by one or two additional bytes containing these larger operands.
• Mnemonics: Because working directly with binary patterns like 11DDDSSS or raw bytes like 01011010 is incredibly difficult for humans, assembly languages were created. A mnemonic is a short, symbolic name (like MOV, ADD, JMP) that represents a specific opcode. An assembler program translates mnemonics and operand names (like register names A, B, C) into the raw machine code bytes.

Example Concept (Illustrative of 8008 approach):

Imagine you want the 8008 to add the value in register B to the value in register A.

1. You might look up the "Add" instruction in the 8008 documentation (the opcode table).
2. You'd find an opcode pattern related to ALU operations, potentially embedding the source register and the specific ALU function (Add).
3. Let's hypothesize a pattern like 100ALUSSS where 100 signifies an ALU operation, ALU specifies the function (e.g., 000 for Add), and SSS specifies the source register (e.g., B is register code 001). The destination (register A) might be implicit for Add operations.
4. The resulting 8-bit opcode might be 100000001 (binary) or A1 (hexadecimal).
5. The assembly mnemonic would be something like ADD B.

This shows how the binary opcode byte A1 is the machine's representation of the command "Add the contents of register B to register A." The assembly mnemonic ADD B is just a human-friendly alias for that specific byte pattern.

This direct embedding of parameters within the opcode is a powerful technique seen in various architectures, demonstrating how the very pattern of 0s and 1s isn't just an identifier, but can also carry functional data.

---

Beyond the Silicon: Opcodes in Software (Bytecode)

The concept of opcodes isn't confined to physical CPU hardware. It's also extensively used in software-based execution environments, particularly those using virtual machines (VMs).

Definition: Bytecode

An intermediate representation of computer code, compiled from a higher-level language but not yet in the native machine code format of a specific CPU. Bytecode is designed to be executed by a software interpreter or a virtual machine, rather than directly by hardware.

Bytecode is essentially a set of instructions for a hypothetical, software-defined processor (the virtual machine). Just like machine code, bytecode instructions consist of opcodes and operands.

Why use bytecode and software opcodes?

• Portability: Code compiled to bytecode can run on any platform that has a compatible virtual machine, regardless of the underlying CPU architecture. This is the core principle behind Java's "write once, run anywhere."
• Security: VMs can provide a sandboxed environment, controlling what the code can access and preventing malicious operations from directly interacting with the host system's hardware or memory.
• Higher Abstraction: Bytecode opcodes often operate on slightly higher-level data types (like Java objects or .NET types) and concepts than raw hardware opcodes, simplifying the compilation process from high-level languages.

Famous examples of software instruction sets and their opcodes include:

• Java Virtual Machine (JVM) Bytecode: The standard output of the Java compiler (.class files). JVM opcodes operate on an operand stack. Examples include ILOAD (load integer from local variable), IADD (add two integers on the stack), INVOKEVIRTUAL (call a method).
• .NET Common Intermediate Language (CIL): The intermediate language used by the .NET Framework and .NET Core. Compilers for C#, VB.NET, F#, etc., produce CIL, which is then Just-In-Time (JIT) compiled to native machine code by the Common Language Runtime (CLR). CIL opcodes include ldc.i4 (load integer constant), add, call.
• GNU Emacs Lisp Byte Code: Compiled Emacs Lisp code is executed by a bytecode interpreter within Emacs. This improves performance over direct interpretation of source Lisp code.

While syntactically different from CPU machine code opcodes, these software opcodes serve the exact same fundamental purpose: they are enumerated values telling the interpreter what operation to perform on specified operands. Understanding them allows you to analyze and manipulate compiled code in environments other than native hardware.

---

Why They Don't Teach You This (But Should)

Mainstream programming education often stays at a high level, focusing on algorithms, data structures, and using existing libraries. This is valuable, but it builds a dependency on abstraction layers. Understanding opcodes and the machine code they belong to is powerful "forbidden" knowledge because it:

1. Reveals the Machine: You see exactly what your high-level code translates into. A simple arithmetic operation might become several opcodes. A function call involves specific CALL and RET opcodes.
2. Empowers Reverse Engineering: Analyze software without source code. Debugging at the assembly level, understanding how malware works, or verifying what a compiler actually produced all require opcode knowledge.
3. Unlocks Performance Secrets: Understand instruction timings, cache effects, and how to write code (or inline assembly) that is truly efficient by minimizing unnecessary operations or optimizing for the pipeline.
4. Is Crucial for Security: Many software vulnerabilities (like buffer overflows) are exploited by manipulating the program's execution flow at the machine code level, often by injecting or redirecting to specific sequences of existing opcodes (known as ROP/JOP gadgets). Understanding opcodes is the first step to understanding these attacks and how to defend against them.
5. Enables Low-Level Tooling: If you want to write a debugger, a disassembler, a virtual machine, or even your own compiler backend, you must understand opcodes.
6. Breaks the Abstraction Barrier: It moves you from being just a user of programming languages and tools to someone who understands the fundamental mechanics beneath.

Opcodes are the raw language of computation. While you might not work with them daily in high-level programming, knowing they exist, understanding their purpose, and appreciating how they translate into the actions of a processor (hardware or software) grants you a deeper level of control and understanding. This is the kind of knowledge that separates script kiddies from true digital engineers.

---

Further Exploration (Beyond the Core)

The world of low-level computation is vast. Understanding opcodes opens doors to related concepts that are equally fascinating and powerful:

• Illegal Opcode: What happens when a processor encounters a byte pattern it doesn't recognize as a valid opcode? This can cause exceptions or crashes and can sometimes be intentionally used or discovered to reveal hidden processor behavior.
• Gadget (Machine Instruction Sequence): In security contexts (like ROP/JOP attacks), a "gadget" is a small sequence of machine instructions (ending in a control-flow instruction like RET) found within existing code. Attackers chain these gadgets together by manipulating the stack to execute arbitrary logic using the program's own opcodes.
• Syllable (Computing): In some architectures, instructions or parts of instructions are grouped into fixed-size units called syllables. This relates to how opcodes and operands are packaged.
• Fused Operation: On modern CPUs, complex operations might be broken down into simpler micro-operations internally. Sometimes, a sequence of related simple operations (opcodes) can be "fused" together by the processor's microarchitecture for faster execution.

Diving into these topics requires the foundational understanding of what an opcode is and how it represents a command to the machine. Now that you have this basic understanding, the path into the digital underground is clearer. Keep exploring.